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Background of the Invention 

1, Technical Field 

The present invention relates to an onshore/offshore software application assessment 
process and tool for distributing workforce resources between onshore and offshore locations for 
supporting the software application. 

2, Related Art 

Some organizations (e.g., corporations) have migrated software applications offshore 
(e.g., to hidia, Latin America, etc.) due to shortage of available manpower in the United States 
and lower costs offshore, often resulting in higher quality development and maintenance of the 
software applications at lower costs. Moving a software application from onshore (i.e., within 
the United States) to offshore (i.e., outside of the United States) is a complex task that may 
involve the replacement of an experienced with an equally capable staff who requires knowledge 
the software and the envirormient in which the software operates. Thus, there is a need for 
methodology and associated tool for managing the migration of the software application fi-om 
onshore to offshore. 

Summary of the Invention 

The present invention provides a method for assessing and managing a plurality of 
software applications for offshore migration, comprising the steps of 
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computing for each of said applications an application assessment score; and 
selecting a delivery model for each of said applications, said delivery model being 
selected from the group consisting of an onshore model, an offshore model, and an onshore- 
offshore mode, said delivery model being selected as function of the application assessment 
score. 

The present invention provides a computer program product, comprising: 
a computer usable medium having a computer readable program code embodied therein 
for assessing and managing a plurality of software applications for offshore migration, said 
computer readable program code adapted to execute the steps of: 

computing for each of said applications an application assessment score; and 
selecting a delivery model for each of said applications, said delivery model being 
selected from the group consisting of an onshore model, an offshore model, and an onshore- 
offshore mode, said delivery model being selected as function of the application assessment 
score. 

The present invention provides a methodology and associated tool for planning and 
managing the migration of a software application from onshore to offshore. 



Brief Description of the Drawing s 

FIG. 1 is a flow chart describing an application assessment and migration procedure, in 
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accordance with embodiments of the present invention. 

FIGS. 2-8 depict an "Assessment" worksheet of a spreadsheet which performs an 
AppHcation Assessment of FIG. 1, in accordance with embodiments of the present invention. 

FIGS. 9-10 depict formulas used to calculate values of calculated fields of the spreadsheet 
5 of FIGS. 2-8, in accordance with embodiments of the present invention. 

Fig. 11 is a table that lists partitions and groups derived from the spreadsheet of FIGS. 2- 
8, in accordance with embodiments of the present invention. 

FIG. 12 is a table describing an ordering sequence for migration of the partitions listed in 
FIG. 1 1, in accordance with embodiments of the present invention. 
1 0 FIG. 1 3 is a table showing a migration timeline relating to the ordering sequence in FIG. 

12, in accordance with embodiments of the present invention. 

FIG. 14 is a table describing the Application Assessment Factors in the spreadsheet of 
FIGS. 2-8, in accordance with embodiments of the present invention. 

FIG. 15 is a table correlating a the delivery model with the Application Assessment 
1 5 Score, in accordance with embodiments of the present invention. 

FIG. 1 6 is a table correlating the AT column with the AS column of the spreadsheet of 
FIGS. 2-8, in accordance with embodiments of the present invention. 

FIG. 1 7 is a table correlating the BI column with the BH column of the spreadsheet of 
FIGS. 2-8, in accordance with embodiments of the present invention. 
20 FIG. 1 8 is a table describing the Documentation Factors in the spreadsheet of FIGS. 2-8, 

in accordance with embodiments of the present invention. 
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FIG. 19 is a table the availability of documentation with the Documentation Score, in 
accordance with embodiments of the present invention. 

FIG. 20 is a table providing guidelines for distributing a workforce between onshore and 
offshore, in accordance with embodiments of the present invention. 

FIG. 21 illustrates a computer system for assessing and managing a plurality of software 
applications for offshore migration, in accordance with embodiments of the present invention. 

FIG. 22 depicts a "Controls" worksheet of the spreadsheet of FIGS. 2-8 wherein the 
"Controls" worksheet includes tables for implementing a LOOKUP command, in accordance 
with embodiments of the present invention. 

FIGS. 23A-2F depict a "Instructions" worksheet of the spreadsheet of FIGS. 2-8 wherein 
the "Instructions" worksheet provides instructions for entering data in the "Assessment" 
worksheet of FIGS. 2-8, in accordance with embodiments of the present invention. 

Detailed Description of the Invention 

Definitions 

An "application" or "software application" is a software application comprising any 
computer program software adapted to be stored on a computer usable medium and adapted to be 
executed on a computer processor. Examples of applications mclude, inter alia: system software 
(e.g., operating system software, input/output interface software, etc.); business application 
software (e.g., accounting software, product inventory software, human resoxirces software, 
product tracking software, equipment inventory software, client database software, etc.); 
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engineering software (plant operations software, acoustics and vibrations software, structural 
analysis software, nuclear reactor physics software, etc.); mathematics software (e.g., statistical 
analysis software, graphics software, linear analysis software, etc.). The terms "application" and 
"software application" will be used interchangeably and are assumed to have an identical 
meaning herein. 

"Onshore" pertains to land within a given country (e.g., the United States). For example, 
Illinois and Alaska are onshore if the given country is the United States. 

"Offshore" pertains to land outside of the given country, including land having a border 
in common with an exterior border of the given country. For example, Mexico and India are 
offshore if the given country is the United States. 

"Nearshore" is a special case of "offshore" and pertains to land outside of the given 
country wherein said land has a border in common with an exterior border of the given country. 
For example, Mexico is nearshore if the given country is the United States. 

For convenience, the embodiments described herein assume that the given country 
associated with onshore is the United States. However, it is within the scope of the present for 
any country in the world to be the onshore country. 

Introduction 

The present invention determines what applications are most appropriate for moving 
offshore and what applications are least appropriate for moving offshore. Thus, the present 
invention provides a methodology for geographically positioning/delivering a software 
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application in accordance with one of three delivery models: an Onshore mode, an Onshore- 
Offshore model, or an Offshore model. With the Onshore model all workforce resources (i.e., 
people constituting the onshore team) are to be located onshore and all functional (i.e., high level 
designs, high level work effort estimates, requirements, user testing support, etc.) and detailed 
tasks (i.e., detailed level tasks like coding, unit testing, detailed sizing/designs, etc.) will be 
performed by the onshore team. With the Offshore model all workforce resources are to be 
located offshore and all functional and detailed tasks will be performed by the offshore team. 
The Onshore-Offshore iaodel iseparates functional and detailed tasks between the onshore and 
offshore teams. With the Onshore-Offshore model, a first portion of the team is onshore within 
the United States and a second portion of the team is offshore (e.g., in India). For example, 20% 
of the team may be located in the United States, and 80% of the team may be located in India. 
The two portions of the team work together to collectively support the application. Each delivery 
model has a unique set of characteristics that will help identify the offshoreability of applications 

The Onshore model is appropriate for an application that: is highly volatile, is unstable, 
has legal or export restrictions, requires real-tune support, reqmres a high level of customer 
interaction, requires high interfacing with other resources, is written with proprietary or third 
party software with limitations for moving support offshore, has stringent security requirements, 
and/or has little or no retum-on-investment potential due to "sunset" (i.e., scheduled to be retired 
shortly such as 18 months or less). 

The Offshore model is appropriate for an application that: is very stable, is highly 
autonomous, has a well-defined scope, follows well-defined requirements, requires few customer 
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interactions, is supported by contractors, and/or has a planned sunset date of less than 1 8 months 
such that a return on investment is expected to be realized within this 1 8-month period. 

The Onshore-Offshore model is appropriate for an application that: is stable (including 
business critical apphcations that have been stabilized), has a well defined scope, follows well- 
defined requirements, is supported by a staff that is geographically distributed and works from 
remote locations, requires high interfacing with other resources such that the interfacing 
application support will move jointly offshore and there is no dependency on restricted 
production data or support, is supported by a high number of contractors, and/or has a praiined 
sunset date of less than 18 months such that a return on investment is expected to be reaUzed 
withm this 1 8-month period, 

FIG. 1 is a flow chart describing an application assessment and migration procedure, in 
accordance with embodiments of the present invention. FIG. 1 depicts a first phase for 
determining candidate applications for offshore migration, followed- by a second phase for 
implementing the migration for each such candidate application. The first phase in FIG. 1 (i.e.. 
Application Assessment and Planning) comprises the sequential processes of: Application 
Assessment 31, Partition Definition 32, Partition Sequence Definition 33, and Master Migration 
Schedule Generation 34. 

The Application Assessment 3 1 performs an application assessment for each application 
that results in an application assessment score (e.g., from 1 to 50), and based on said application 
assessment score the Application Assessment 31 determines which of the three delivery models 
(i.e., Onshore, Offshore, or Onshore-Offshore model) is appropriate for the application so 
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assessed. 

The Partition Definition 32 partitions the assessed applications into logical groupings (or 
"partitions") such that each logical grouping can be moved from onshore to offshore as a unit of 
work. The logical groupings may be based on business area, business function, technology area, 
etc. The logical groupings may be further refined to balance the mix of applications based on 
business criticality, business complexity, and staffing distribution. 

The Partition Sequence Definition 33 sequences the logical groupings for migration of 
from onshore to offshore in a manner that minimally impacts the business. The partitions are 
sequenced such that partitions with a low average application assessment score(to be explained 
infra in conjunction with FIG. 1 1), high stability, and low to medium complexity are to be moved 
first. Factors to be considered in the sequencing include: business, technical, resource, and 
project dependencies. The sequencing may be further refined by reviewing overall partition 
criticality and support levels. - 

The Master Migration Schedxile Generation 34 generates a Master Migration Schedide 
(see FIG. 1 3 for an example) for implementing the group migrations sequenced by the Partition 
Sequence Definition 33. Generating the Master Migration Schedule may include: defining the 
time scope of the migration timeline, defming the overall migration strategy, identifying and 
planning for project dependencies and risks, developing individual partition schedules, and 
scheduling guidelines for each partition (typically 4 to 5 months for migration in functional steps 
of multiples of one month). 

The second phase (i.e, Application Migration) in FIG. 1 comprises, for each migrating 
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application 50, the sequential processes of: Application Migration Planning 41, Knowledge 
Transfer 42, Parallel Perform 43, Application Cutover 44, and Steady State 45. 

The Application Migration Planning 41 takes mto account the resoxirce requirements, 
what tasks have to be performed, etc, in order to subsequently transfer knowledge about the 
application from onshore to offshore. 

The Knowledge transfer 42 occurs during a period in which the application team goes 
through, inter alia: classroom training for supporting the applications and/or guided performance 
training. ^ - ^ - 

The Parallel Perform 43 includes a period of time during which the new offshore team of 
people perforai the application and if the offshore team run into trouble, the previous team that 
existed just prior to the onset of the offshore team is adapted to assist and help the offshore team. 

The Application Cutover 44 is an interface between the Parallel Perform 43 and the 
Steady State 45. 

The Steady State 45 is characterized by onshore and offshore teams being in place such 
that the offshore team is running and the application is being managed autonomously by the 
offshore tem. 

The Application Assessment and Planning phase of FIG. 1 will be next discussed, with 
respect to: Application Assessment 31, Partition Definition 32, Partition Sequence Definition 
33, and Master Migration Schedule Generation 34. The scope of the present invention includes 
implementing each of Application Assessment 31, Partition Definition 32, Partition Sequence 
Definition 33, and Master Migration Schedule Generation 34 by execution of computer readable 
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program code embodied in a computer usable medium. 

Application Assessment 

In relation to Application Assessment 1 1 of FIG. 1, each application is assessed based on 
Application Assessment Factors, comprising: business criticality, operational criticality, 
5 application complexity, application profile, and other factors. The Application Assessment 

Factors are weighted to place greater importance on those factoris having a higher business focus. 
FIG. 14 depicts a description of the Application Assessment Factors and their weightings. 

The business criticality relates to the business as a whole; e.g., if the appUcation is down 
then the business stops. In contrast, operational criticality relates to intemal interfaces within the 
10 business; e.g., if the application is down then other applications may be impacted. The ''Other 
Factors" category is a catch-all category and may include, inter alia, factors specific to an 
industry (e.g., certain billing software may be a critical issue for a telecommunications company; 
but billing may not be a material concem for other industries, so that for a telecommxmication 
company billing software may be too critical to export to offshore). Additionally, the weightings 
15 in FIG. 14 are for illustrative purposes only, and any set of weighting factors are within the scope 
ofthe present invention. 

Each Application Assessment Factor is quantified and totaled to establish the application 
assessment score. In some embodiments, 65 to 70 percent of a client's application portfolio will 
fall within the Offshore or Onshore-Offshore delivery model, while 30 to 35 percent of the 
20 client's application portfolio will include key business/mission critical applications that will be 
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supported with an Onshore delivery model, 

FIG. 15, which is applicable to some embodiments of the present invention, lists ranges 
of the application assessment score of an application for providing guidance to determine the 
appropriate delivery model for the application. FIG. 1 5 depicts a range of "Application 
Assessment Score" for each dehvery model, on a scale from 1 to 50. The "Expected % of 
Applications" is the estimated percent of applications expected to fall within each delivery 
model, and the listed percents in FIG. 5 are merely illustrative. The actual "Expected % of 
Applications" is case-dependent and will vary from one organization to another, or from one 
industry to another. 

FIGS. 2-8 collectively depict an "Assessment" worksheet of an EXCEL® spreadsheet, 
wherein said "Assessment" worksheet performs the Application Assessments! of FIG. l,in 
accordance with embodiments of the present invention. Each Figure of FIGS. 2-8 displays the 
same spreadsheet rows 1-21, wherein the row numbers 1-21 are shown in the leftmost column of 
each Figure. Of the rows 1-21, rows 12-18 each represent a single application, and rows 19-21 
are essentially empty and therefore do not represent applications. 

FIG. 22 depicts a "Controls" worksheet of the spreadsheet of FIGS. 2-8 wherein the 
"Controls" worksheet includes tables for implementing a LOOKUP command appearing in 
formulas for selected calculated fields of the" Assessment" worksheet, in accordance with 
embodiments of the present invention. 

FIGS. 23A-23F (collectively, FIG. 23) depict a "Instructions" worksheet of the 
spreadsheet of FIGS. 2-8 wherein the "Instructions" worksheet provides instructions for entering 
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data in the "Assessment" worksheet of FIGS. 2-8, in accordance with embodiments of the 
present invention. 

FIGS. 2-8 each represent a different groups of columns of the "Assessment" worksheet of 
the spreadsheet, sequentially ordered from left to right. In particular, FIG. 2 depicts columns A 
to F, FIG. 3 depicts columns H to S, FIG. 4 depicts columns U to AI, FIG. 5 depicts columns AK 
to AT, FIG. 6 depicts columns AV to BI, FIG. 7 depicts columns BK to BV, and FIG. 8 depicts 
columns BX to CH. 

Whenever the description herein infra of the "Assessment" worksheet of FIGS. 2-8 refers 
to the contents of a column but does not identify specific rows, it is to understood that the 
description is actually referring to the data content of the cells defmed by the intersection of the 
column with rows 12, 13, 14, .... 

FIG. 2 displays a legend in the cells defined by columns A-B and rows 3-7. The legend is 
applicable to each Figure of FIGS. 2-8. The legend identifies, by the indicated shading, which 
fields are enterable fields, which fields are calculated fields, and which fields contain control 
totals. A control total for a given column is calculated as a summation of all numerical values 
appearing in the cells of the given column. 

The cells having calculated fields each include a calculated value (e.g., a numerical value, 
a text value, etc.) in accordance with the formulas listed in FIGS. 9 -10, in accordance with 
embodiments of the present invention. The formulas in FIGS. 9-10 are expressed in accordance 
with the EXCEL® language for articulating formulas. While the formulas listed FIGS. 9-10 are 
particularized for row 12, said formulas of FIGS. 9-10 are applicable to any given row of rows 12, 
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13, 14, provided that the "12" is replaced by the row number of the given row. 

FIG. 2 depicts the following information for each application: business area, business 
function, application ID, application name, and application description. 

FIG. 3 depicts the following information for each application: hardware platform, software 
5 platform, database used by the application, application language, package flag (i.e., Y: off the 
shelf N: not off the shelf), package vendor, age, number of users supported, and life expectancy. 

FIG. 4 includes columns which describe the distribution of full-time employees (FTE) by 
. function/activity for each application. Columns U-AC of FIG. 4 lists the percentage of full-time 
employees (FTE) engaged in various functions/activities: percent of FTE doing break/fix of the 
1 p software (i.e., percent of FTE devoted to repair/maintenance of the application), percent of FTE . 
doing enhancements of the software, percent of FTE doing ad hoc support, percent of FTE doing 
testing, percent of FTE doing rollout (i.e., deployment), percent of FTE doing customer facing 
(i.e., customer interaction), percent of FTE doing project management, percent of FTE doing 
development, and percent of FTE doing otiier activities. The total of said percentages for each 
15 application are a calculated field in column AD (in rows 12, 13, 14, ...), which is computed by 

adding the cells in columns U through AC (see formula for AD 12 in FIG. 9). Column AE lists the 
location of the appUcation. Columns AF, AG, and AH indicate the number of FTEs (called **team 
size") having more than 6 years experience, 3 to 6 years experience, and less than three years 
experience, respectively. The total of said FTEs for each application is a calculated field in 
20 column AI (in rows 12, 13, 14, ...), which is computed by adding the cells in colimms AE through 
AG (see formula for AI12 in FIG. 9). 
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FIG. 5 includes columns of data for computing three of the Application Assessment 
Factors required for the Application Assessment 31 of FIG. 1, namely: business criticality 
(column AK), operational criticality (column AL), and application complexity (columns AN-AR). 
The business criticality has a score from 1 to 5 in order of increasing business criticality. The 
5 operational criticality has a score .from 1 to 5 in order of increasing operational criticality. The 
application complexity is broken down into five complexity components: code complexity 
(column AN), data complexity (colxmm AO), business complexity (column AP), problem 
complexity (column AQ), and application stability (column AR). Each of said complexity 
components has a score from 1 to 5 in order of increasing complexity. 

10 Column AS includes a calculated field (in rows 12, 13, 14, ...) that contains the 

Application Complexity Score for each application, by summing the scores of the complexity 
components. Thus, the Application Complexity Score is pomputed by adding the cells in columns 
AN through AR for each application (see formula for AS 1 2 in FIG. 9). 

Column AT includes a calculated field (in rows 12, 13, 14, ...) that contains the 

1 5 Complexity Rating for each application as indicated FIG. 1 6 in accordance with the formula for 
AT12 in FIG. 9. The Complexity Rating has a value of 1 to 5 in order of increasing Application 
Complexity Score. 

FIG. 6 includes columns of data for computing the Application Profile factor of the 
Application Assessment Factors required for the AppUcation Assessment 31 of FIG. 1. Colimms 
20 AV, AW, AX, AY, AZ, BA, and BB respectively include: Number of concurrent users, Number 
of software modules (denoted as "LOC or Modules"), Number of Severity- 1 reports per month, 
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Number of Severity-2 reports per month, Number of major/minor releases per month, 
Major/minor Releases Effort in PTEs or total hours, and Level of customization (1 to 5 in order of 
increasing degree of customization), 

A Severity- 1 incident occurs if upon an application going down, one or more other 
5 applications are negatively impacted such as likewise going down. A Severity-2 incident occurs 
if upon an application going down, workarounds exists such that other apphcations are not 
impacted and do not consequently go down. 

Columns BC-BI of FIG. 6 each include calculated fields (in rows 12^ 13, 14, ...). Column 
BC includes the calculated field containing a "Concurrent User's Score" computed according to 
10 the function LOOKUP, based on the Number of Concurrent Users in column AV (see formxila for 
BC12 in FIG. 9). The Concurrent User's Score in column BC is rated on a scale if 1 to 5 in order 
of increasing Number of Concurrent Users. Note that tiie function LOOKUP accesses data in the 
"Controls'' worksheet of FIG. 22.. 

Colmnn BD includes the calculated field containing a "LOC or Modules Score" computed 
1 5 according to the function LOOKUP, based on the LOCs or Modules in column AW (see formula 
for BD12 in FIG. 9). The LOC or Modules Score in column BD is rated on a scale if 1 to 5 in 
order of increasing LOCs or Modules. 

Column BE includes the calculated field containing a Severity- 1 Score computed 
according to the function LOOKUP, based on the Number of Severity- 1 reports per month in 
20 column AX (see formula for BE12 in FIG. 9). The Severity-1 Score in column BE is rated on a 
scale if 1 to 5 in order of increasing Number of Severity-1 reports per month. 
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Column BF includes the calculated field containing a Severity-2 Score computed 
according to the function LOOKUP, based on the Number of Severity-2 reports per month in 
column AY (see formula for BF12 in FIG. 9). The Severity-2 Score in column BF is rated on a 
scale if 1 to 5 in order of increasing Number of Severity-2 reports per month. 
5 Colunrn BG includes the calculated field containing a Major/Minor Release Score 

computed according to the function LOOKUP, based on the Number of major/minor releases per 
month in colxmm AZ (see formula for BG12 in FIG. 9). The Major/Minor Release Score in 
column BG is rated on^a scale if 4 to 5 in order of increasing Number of major/minor releases per 
month. 

10 Column BH includes the calculated field containing an Application Profile Score 

computed as a summation over the contents of the scores in colimms BB to BG (see formula for 
BH12inFIG.9). 

Column BI includes the calculated field containing an Application Profile Rating as 
indicated in FIG. 17 in accordance with the formula for BI12 in FIG. 9. The Application Profile 
1 5 Rating has a value of 1 to 5 in order of increasing Application Profile Ratmg. 

FIG. 7 includes columns BS-BV, each containing calculated fields in rows 12, 13, 14, 
which comprise scores associated with the Application Assessment Factors of FIG. 14. Row 9 of 
columns BS-BV contain the weighting factors of FIG. 14. 

' Column BS includes the calculated field containing a "Business Criticality Score" 
20 computed according to the product of the Business Criticality rating in column AK (see FIG. 5) 
and the applicable weight in cell BS9 (see formula for BS12 in FIG. 10). 
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Column BT includes the calculated field containing a "Operational Criticality Score" 
computed according to the product of the Operational Criticality rating in column AL (see FIG. 5) 
and the applicable weight in cell BT9 (see formula for BT12 in FIG. 10). 

Column BU includes the calculated field containing a "Application Complexity Score" 
computed according to the product of the Complexity rating in column AT (see FIG. 5) and the 
applicable weight in cell BU9 (see formula for BU12 in FIG. 10). 

Column BV includes the calculated field containing a "Application Profile Score" 
.^computed according to the product of the Application Profile rating in column BI (see FIG. 6) and 
the applicable weight in cell BV9 (see fomiula for BV12 in FIG. 10). 

FIG. 8 includes columns having calculated fields and relating to completing the 
Application Assessment 31 of FIG. 1, namely columns BX, BY, CA, CB, CC, CD, CF, CG, and 
CH. 

Column BY is a calculated field containing the Application Assessment Score in rows, 12, 
13, 14, calculated by adding scores associated with the Application Assessment Factors, said 
scores being in columns BS-BV of FIG. 7 (see formula for BY12 in FIG. 10). Thus the 
Application Assessment Score is computed in the presentiy described embodiment as a weighted 
linear function of the following variables: business criticality rating, the operational criticality 
rating, the application complexity rating, and the application profile rating. However, the scope of 
the present invention includes an embodiment in which the Application Assessment Score is 
computed as a weighted nonlinear fimction of the following variables: business criticality rating, 
the operational criticality rating, the application complexity rating, and the application profile 
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rating (which means that the dependence on at least one of said variables in nonlinear). It should 
be noted that weighting of each variable (in either the linear or nonlinear embodiment) may be 
zero or non-zero; a weighting of zero for a given variable would make the Application 
Assessment Score independent of the given variable 
5 Column BX is a calculated field containing the delivery model for each application (in 

rows 12, 13, 14, ...). In column BX "Onsite" and "Remote" respectively means "Onshore" and 
"Offshore". The formula for determining the deliveiy model in column BX is given as the 
formula for calculating BX12 in FIG. 10. The features of this formula include: 

1) BX is a function of the Application Assessment Score contained in column BY 

10 according to: BX="Onsite" if BY>40, BX="Remote" if BY^ 10, and BX="Onsite/Remote" if 

1 1 ^BY^40 (note that the preceding dependence of BX on BY differs from the dependence of BX 
on BY in FIG. 15 which is acceptable since the scope of the present invention does not constrain 
the dependence of BX on BY to a specific relationship); 

2) The preceding calculation of BX in 1) above is subject to an override (i.e., a delivery 
15 model override) based other special conditions; e.g., BX="CriticalApp & Unstable" if AK=5 and 

AR>3 (Business Criticality rating =5 and StabiHty rating >3), which occurs in cell BX18; and 

3) The preceding calculation of BX in 1) and 2) above is subject to another delivery model 
override, namely an override input in colunrn CA. 

Columns CF, CG, and CH are calculated fields collectively containing the delivery model 
20 for each application (in rows 12, 13, 14, ,..), based on colxmm BX with a further dependence on 
column CA (see formulas for CF12, CG12, and CH12 m FIG. 10). Note that "1 " denotes that the 
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associated delivery model is used for the application, and "0" denotes that the associated delivery 
model is not used for the application. For example, the "1" in cells CG12, CG13, CG14, CG16, 
and CG17 indicates that the application of rows 12-17 each have the Onsite/Remote delivery 
model, which is derived from the fact that the Onsite/Remote delivery model is contained in cells 
5 BX12-BX17. The "CriticalApp & Unstable" value in cell BXl 8 translates to the Onsite model in 
cellCFlS. 

Columns CB, CC, and CD are calculated fields containing the distribution of PTEs with 
respect to the Onsite, Onsite/Remote, and Remote delivery models. As may be seen in FIG. 8, the ' 
pattern of "0" and " 1 " in columns CF, CG, and CH is repeated m columns CB, CC, and CD, 
1 0 respectively^ except that " 1 " is replaced by the total number of FTEs contained in column AI of 
FIG. 4 (see formula for CB12, CC12, and CD12 in FIG. 10). 

Partition Definition 

In relation to Partition Definition 32 of FIG. 1, a partition represents a group of 
appUcations that will migrate fi:om onshore to ofiishore together. FIG. 1 1 depicts the partitions, 
1 5 derived from column A of FIG, 2 on the basis of a common business area. Thus the partitions 
Usted in FIG. 1 1 are: Logistics, Finance, and HR. Payroll is a grouping, but not a partition, but 
rather is a group of applications that will remain onshore, because Payroll is an Onshore grouping 
as mdicated in cell CF18 of FIG. 8. 

The partitions and groupings may alternatively be based on other criteria such as, inter 
20 alia, business function, technology area, team size (in terms of the number of FTEs), call volumes 
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(i.e., helpdesk and non-helpdesk), internal and external dependencies, project activity, etc. 

The Application Count is the number of applications in each business area as deduced 
from col. A of FIG. 2. 

The average Application Assessment Score for each partition or grouping is the arithmetic 
average of the Application Assessment Scores for the applications in each partition or grouping, 
as listed in column BY of FIG. 8. For example, column A of FIG. 1 identifies the Logistics 
partition as relating to rows 16 and 17. Since the Application Assessment Scores for rows 16 and 
17 are 26 and 23.5, respectively, the average Application Assessment Score.for.the Logistics 
partition is 24.75 (i.e., [26+23. 5]/2). Note that the partitions are ordered (from top to bottom) in 
FIG. 11 by the average Application Assessment Score. 

The Total FTEs for each partition is the summation of the FTEs of the applications in the 
partition, as derived from column AI of FIG. 4 (or from colunms CB, CC, and CD of FIG. 8). For 
example, column A of FIG. 1 identifies the Finance partition as relating to rows 12 and 13. Since 
the FTEs for rows 12 and 13 are 55 and 27, respectively, the Total FTEs for the Finance partition 
is 82 (i.e., 55+27). 

Partition Sequence Definition 

In relation to Partition Sequence Definition 32 of FIG. 1, FIG. 12 lists the partitions of 
FIG. 1 1 in order of migration (from top to bottom) to offshore. The duration of migration for each 
partition in FIG. 12 includes the foUowdng sequential processes of Application Migration 
depicted in FIG. 1 : Application Migration Planning 41, Knowledge Transfer 42, and Parallel 
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Perform 43. The duration of migration for each partition in FIG. 12 relates to factors such as, 
inter alia, an average Documentation Score (discussed infra), the size of the application (i.e., 
number of program modules or lines of code, etc.), application complexity, resource availability, 
etc. The order of migration in FIG. 12 relates to the order of average Application Assessment 
5 Score in FIG. 1 1 (listed again in FIG. 12) and also to the duration of migration for each partition. 
Consequently, the order of migration of the partitions may relate to the average Documentation 
Score through the dependence of the duration on the average Documentation Score. 

As to the effect of tlie Application Assessment Score on the order of migration, the least 
critical and least complex applications should be migrated first, and the more critical and complex 

10 applications should be relatively later migrated.. Additionally, the earlier and less complex 

applications can be migrated more quickly as reflected in the duration of 3, 4, and 5 months for 
the Logistics, Finance, and HR partitions respectively. 

As to the effect of the average Documentation Score on the duration of migration of each 
partition, FIG. 7 of the spreadsheet includes Documentation Factors in columns BK - BQ, their 

15 scores for each application in rows 12, 13, 14, and their associated weights in row 9. The 
Dociunentation Factors are rated on a scale from 1 to 5 with the a rating of 1 being the lowest 
rating indicative of a low level of documentation, and a rating of 5 being the highest rating 
indicative of a high level of documentation. FIG. 1 8 provides a description of the Documentation 
Factors along with their associated weights. The weights in FIG. 18 are merely illustrative, and 

20 any set of weights may be used. 

FIG. 8 includes column BZ which is a calculated field containing a Docvmientation Score 
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in rows 12, 13, 14, .... The Documentation Score is a linear combination of the Documentation 
Factors in accordance with the weights, multipUed by 10 (see formula for BZ12 m FIG. 10). For 
example, the documentation factor for row 12 is 27 (i.e., 10x[.25x5 +.15x3 +.10x2 + .05x2 + 
.20x1 +.15x2 + .10x2]). 

FIGS. 1 1 andl2 each list the average Documentation Score for each partition and group, as 
averaged over the applications in each partition and group. 

FIG. 19, which is applicable to some embodiments of the present invention, lists ranges of 
the documentation score of an appUcation for providing guidance to determine the cycle length - 
(i.e., months) for migrating applications to offshore. Generally, the more available the 
documentation, the shorter the cycle length. A higher availability is associated vnih a higher 
Documentation Score. 

» Returning to FIG. 1 2, the order of migration is a function of the average Application 
Assessment Score and the average Documentation Score. As can be seen in FIG. 12, the Logistics 
partition (which has the lowest average AppHcation Assessment Score and the highest average 
Docimientation Score) will have the shortest migration duration of 3 months and be first to 
migrate to offshore, while the HR partition (which has the highest average Application 
Assessment Score and the lowest average Documentation Score) will have the longest migration 
duration of 5 months and be last to migrate to offshore. However, the order of migration may take 
into account other factors, such as life expectancy and dependencies (i.e., technical, people, and 
project dependencies). 

FIG. 12 also shows "Onshore Percent" of 20% (i.e., the percent of FTEs placed onshore) 
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for each partition and the "Offshore Percenf'of 80% (i.e., percent of PTEs placed offshore for 
each partition). FIG. 12 also shows the Onshore PTEs (i.e., Onshore Percent x Total PTEs), and 
the Offshore PTEs (i.e., Offshore Percent x Total PTEs). The Onshore Percent of 20% and the 
Offshore Percent of 80% is for illustrative purposes only. Generally, any combination of Onshore 
Percent and Offshore Percent that sums to 100% is within the scope of the present invention. 
PIG. 20 lists various combinations of Onshore Percent and Offshore Percent and the factors that 
favor each such combination. 

Master Migration Schedule Generation 

In relation to Master Migration Schedule Generation 34 of FIG. 1, FIG. 13 depicts a 
Master Migration Schedule, which includes a timeline for implementing the migration of 
applications to offshore. The timeline of FIG. 13 shows that the Logistics partition is migrated 
first, the Finance partition is next migrated, and the HR partition is migrated last. The preceding 
order of migration is in accordance with the order of migration discussed supra in conjunction 
with PIG. 12. 

In the Monthl, Month 2, ... portion of the timeline of PIG. 13, ''PLAN" denotes 
Application Migration 41 depicted in PIG. 1, "KT" denotes Knowledge Transfer 42 depicted in 
FIG. 1, "PARALLEL" denotes Parallel Perform 43 depicted in FIG. 1, and "SS" denotes Steady 
State 45 depicted in FIG. 1. 

To illustrate the timeline of FIG. 13, consider the Finance partition. In accordance with 
the second phase of FIG. 1 (i.e., Application Migration), PIG. 13 shows that: month 3 is devoted 
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to the Application Migration Planning 41 (i.e., "PLAN"), months 4 and 5 are devoted to 
Knowledge Transfer 42 (i.e., "KT"), and month 6 is devoted to Parallel Perform 43 (i.e., 
"PARALLEL") for a duration of 4 months. The Finance partition is in Steady State 45 in month 
7, and the Application Cutover 44 is at the interface between the end of month 6 and the 
beginning of month 7. The Logistics and HR partitions have similar timelines in FIG. 13. 

Additional Aspects of the Invention 

While an EXCEL® spreadsheet was described herein for computing for each application an 
application assessment score and a documentation score (as well as related parameters such as 
assigning PTEs to a delivery model for each application), the scope of the present invention 
includes any commercial or non-commercial spreadsheet capable of having calculated fields with 
associated calculational formulas. The scope of the present invention more generally includes any 
known software computing means for performing any of the calculations and logic that was 
described herein as being performed in accordance with said spreadsheet. Such software 
computing means may include, inter alia, a spreadsheet as discussed supra or a computer program 
written in any applicable computer programming language such as C, C-hh, BASIC, FORTRAN, 
PASCAL, etc. 

FIG. 21 illustrates a computer system 90 for assessing and managing a plurality of 
software applications for offshore migration, in accordance with embodiments of the present 
invention. The computer system 90 comprises a processor 91, an input device 92 coupled to the 
processor 91, an output device 93 coupled to the processor 91, and memory devices 94 and 95 
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each coupled to the processor 91. The mput device 92 may be, inter alia, a keyboard, a mouse, 
etc. The output device 93 may be, inter alia, a printer, a plotter, a computer screen, a magnetic 
tape, a removable hard disk, a floppy disk, etc. The memory devices 94 and 95 may be, inter alia, 
a hard disk, a dynamic random access memory (DRAM), a read-only memory (ROM), etc. The 
memory device 95 includes a computer code 97 (i.e., computer readable program code). The 
computer code 97 may be embodied in a spreadsheet having calculated fields with associated 
calculational formulas, such as the EXCEL® spreadsheet discussed supra in conjunction with 
FIGS. 2-8 and 22-23. The computer code 97 includes an algorithm for assessing andmanaging a 
plurality of software applications for offshore migration. The processor 91 executes the computer 
code 97, The memory device 94 includes input data 96. The input data 96 includes input required 
by the computer code 97. The output device 93 displays output from the computer code 97. 
Either or both memory devices 94 and 95 (or one or more additional memory devices not shown 
in FIG. 21) may be used as a computer usable medium having a computer readable program code 
embodied therein, wherein the computer readable program code comprises the computer code 97. 

While FIG. 21 shows the computer system 90 as a particular configuration of hardware 
and software, any configuration of hardware and software, as would be known to a person of 
ordinary skill in the art, may be utilized for the purposes stated supra in conjunction with the 
particular computer system 90 of FIG. 21 . For example, the memory devices 94 and 95 may be 
portions of a single memory device rather than separate memory devices. 

While embodiments of the present invention have been described herein for purposes of 
illustration, many modifications and changes will become apparent to those skilled in the art. 
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Accordingly, the appended claims are intended to encompass all such modifications and changes 
as fall within the true spirit and scope of this invention. 
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